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Abstract 

Haskell's deriving mechanism supports the automatic generation 
of instances for a number of functions. The Haskell 98 Report 
only specifies how to generate instances for the Eq, Ord, Enum, 
Bounded, Show, and Read classes. The description of how to gen- 
erate instances is largely informal. The generation of instances 
imposes restrictions on the shape of datatypes, depending on the 
particular class to derive. As a consequence, the portability of in- 
stances across different compilers is not guaranteed. 

We propose a new approach to Haskell's deriving mechanism, 
which allows users to specify how to derive arbitrary class in- 
stances using standard datatype-generic programming techniques. 
Generic functions, including the methods from six standard Haskell 
98 derivable classes, can be specified entirely within Haskell 98 
plus multi-parameter type classes, making them lightweight and 
portable. We can also express Functor, Typeable, and many other 
derivable classes with our technique. We implemented our deriving 
mechanism together with many new derivable classes in the Utrecht 
Haskell Compiler. 

Categories and Subject Descriptors D.l.l [Programming Tech- 
niques}: Functional Programming 

General Terms Languages 

1. Introduction 

Generic programming has come a long way: from its roots in 
category theory (Backhou se et al.||1999|>, p assing through dedi- 
cated languages (Jansson and Jeuring 19971, language extensions 
and pre-processors (Hinze et al. 2007, Loh 2004 ) until the flurry 
of library-based approaches of today ( Rodriguez Yakushe v et al.| 
20081. In this evolution, expressivity has not always increased: 
many generic programming libraries of today still cannot compete 
with the Generic Haskell pre-processor, for instance. The same ap- 
plies to performance, as libraries tend to do little regarding code 
optimization, whereas meta-programming techniques such as Tem- 
plate Haskell (Sheard and Peyton Jones 2002) can generate near- 
optimal code. Instead, generic programming techniques seem to 
evolve in the direction of better availability and usability: it should 
be easy to define generic functions and it should be trivial to use 
them. Certainly some of the success of the Scrap Your Boilerplate 
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approach (S YB, Lammel and Peyton Jones 2003 2004 1 is due to its 
availability: it comes with the Glasgow Haskell Compiler (GHC), 
the main Haskell compiler, which can even derive the necessary 
type class instances to make everything work without clutter. 

To improve the usability of generics in Haskell, we believe 
a tighter integration with the compiler is necessary. In fact, the 
Haskell 98 standard already contains some generic programming, 
in the form of derived instances (Peyton Jones et al. 2003, Chapter 
10). Unfortunately, the report does not formally specify how to 
derive instances, and it restricts the classes that can be derived to 
six only (Eq, Ord, Enum, Bounded, Show, and Read). GHC has 
since long extended these with Data and Typeable (the basis of 
SYB), and more recently with Functor, Foldable and Traversable. 
Due to the lack of a unifying formalism, these extensions are not 
easily mimicked in other compilers, which need to reimplement the 
instance code generation mechanism. 

To address these issues, we propose an approach to specifying 
how to derive an instance of a class, together with new behavior for 
the deriving mechanism in Haskell to automatically derive such 
a class. To allow for portability across compilers, our approach 
requires only Haskell 98 with multi-parameter type classes and 
support for a new compiler pragma. Specifically, our contributions 
are: 

• We describe a new datatype-generic programming library for 
Haskell. Although similar in many aspects to other approaches, 
our library requires almost no extensions to Haskell 98; the 
most significant requirement is support for multi-parameter 
type classes. 

• We show how this library can be used to extend the deriving 
mechanism in Haskell, and provide sample derivings, notably 
for the Functor class. 

• We provide a detailed description of how the representation for 
a datatype is generated. In particular, we can represent almost 
all Haskell 98 datatypes. 

• We provide a fully functional implementation of our library 
in the Utrecht Haskell Compiler (UHC, |Dijkstra et al.|2009> . 
Many useful generic functions are defined using generic deriv- 
ing in the compiler. 

We also provide a package which compiles both in UHC and GHC, 
showing in detail the code that needs to added to the compiler, the 
code that should be generated by the compiler, and the code that is 
portable between compilers^ 

The remainder of this paper is structured as follows: first we 
give a brief introduction to generic programming in Haskell ( |Sec-| 
|tion 2\ , which also introduces the particular library we use. We pro- 
ceed to show how to define generic functions l |Section 3| >, and then 

1 http : //dreixel .net/research/code/gdmh. tar .gz 



describe the necessary modifications to the compiler for supporting 
our approach ( |Section 4) . Finally, we discuss alternative designs 
i Section 5\ , review related work {Section 6\ , propose future work 
i Section 7) and conclude in |Section~8| 

2. Generic programming 

We use the generic function encode as a running example through- 
out this paper. This function transforms a value into a sequence of 
bits: 

data Bit = 0\1 

class Encode a where 
encode:: a — > [Bit] 

We want the user to be able to write 

data Exp = Const hit | Plus Exp Exp 
deriving [Show, Encode) 

and to use encode like 

test:: [Bit] 

test = encode (Phis (Const 1) (Const 2)) 

This should be all that is necessary to use encode. The user should 
need no further knowledge of generics, and encode can be used in 
the same way as show, for instance. 

Behind the scenes, the compiler generates an instance for 
Encode Exp based on a generic specification of instances of class 
Encode. There are several ways to specify such an instance, 
both using code generation and datatype-generic approaches. We 
choose a datatype-generic approach because it is type-safe and el- 
egant (Hinze et al. 20071. We will discuss alternative designs and 
motivate our choice in more detail in |Section 5| For now we pro- 
ceed to describe our new generic programming library. The three 
basic ingredients for generic programming, as described by |Hinze] 
|andL6h| f2009), are: 

1 . Support for overloaded functions 

2. A run-time type representation 

3. A generic view on data 

Since we use Haskell, (1) is easy: an overloaded (ad-hoc polymor- 
phic) function is a method of a type class. For (2), we introduce a 
type representation similar to the one used in the regular (Van 
Noort et al. |2008 i and instant-generics (Chakravart y et al.| 
20091 libraries, in |Section 2.1| For (3), we again use type classes 
to encode embedding-projection pairs for user-defined datatypes in 
ISection 2.31 

2.1 A run-time type representation 

The choice of a run-time type representation affects not only the 
compiler writer but also the expressiveness of the whole approach. 
A simple representation is easier to derive, but might not allow 
the definition of some generic functions. More complex representa- 
tions are more expressive, but require more work for the automatic 
derivation of instances. 

We present a set of representation types that tries to balance 
these factors. We use the common sum-of-products representation 
without explicit fixpoints but with explicit abstraction over a sin- 
gle parameter. Therefore, representable types are functors, and we 
can compose types. Additionally, we provide useful types for en- 
coding meta-information (such as constructor names) and tagging 
arguments to constructors. We show examples of how these repre- 
sentation types are used in |Section 2.4| 

The basic ingredients of the sum-of-products representation 
types are: 



dataC// P = Uj 

data (+) 0 iff p =Lj {unL; ::(p p}\Ri {unRj :: y/p} 
data ( x ) 0 \\f p = <j> p x y/ p 

We encode lifted sums with (+) and lifted products with (x). 
Nullary products are encoded with lifted unit 

The type variable p is present in all representation types: it 
represents the parameter over which we abstract. We use an explicit 
combinator to mark the occurrence of this parameter: 

newtype Par/ p = Pari {unParj ::p} 

As our representation is functorial, we can encode composition. 
Although we cannot express this in the kind system, we require the 
first argument of composition to be a representable type construc- 
tor. The second argument can only be the parameter, a recursive 
occurrence of a functorial datatype, or again a composition. We use 
Rec] to represent recursion, and (o) for composition: 

newtype Rec; (j) p = Recj {unRecj ::tj) p } 

newtype (o) <j> t//p = Compi (<j> (y p)) 

PolyP (Jansson and Jeuring 1997) treats composition in a similar 
way. 

Finally, we have two types for representing meta-information 
and tagging: 

newtype AT; i y p = Kj {unK; ::y} 

newtype M] i y <j> p = Mj {unM; ::tf> p} 

We use Kj for tagging and M; for storing meta-information. The 
role of the t parameter in these types is made explicit by the 
following type synonyms: 



dataD typeD/ =M } D 

data C type C, =M,C 

dataS typeS; =M,S 

data R type Rec 0 = K; R 

data P type Par 0 =K, P 



We use Reco to tag occurrences of (possibly recursive) types of 
kind * and Paro to mark additional parameters of kind (other than 
p). For meta-information, we use Dj for datatype information, C; 
for constructor information and Sj for record selector information. 
We group five combinators into two because in many generic func- 
tions the behavior is independent of the meta-information or tags. 
In this way, fewer trivial cases have to be given. We present the 
meta-information associated with M; in detail in the next section. 

Note that we abstract over a single parameter p of kind *. This 
means we will be able to express generic functions such as 

frnap :: (a — > j3) — > <j> a — > <j> j3 

but not 

bimap:: (a^y)-^(j3-^<5)-+0aj6^0y<5 

For bimap we need another type representation that can distinguish 
between the parameters. All representation types need to carry one 
additional type argument. However, we think that, in practice, few 
generic functions require abstraction over more than a single type 
parameter. 

2.2 Meta-information 

For some generic functions we need information about datatypes, 
constructors, and records. This information is stored in the type 
representation: 

2 We also have lifted void (V;) to represent nullary sums, but for simplicity 
we omit it from this discussion and from the generic functions inlSection 31 



class Datatype 7 where 
datatypeName : : y — > String 
moduleName : : y — » String 

class Selector y where 
selName : : y — ► String 
selName = const " " 

class Constructor y where 
conName :: 7 — > String 

conFixity;: y —> Fixity 
conFixity = const Prefix 

conlsRecord:: 7 — > Boo/ 
conlsRecord = const False 

Names are unqualified. We provide the datatype name together with 
the module name. This is the only meta-information we store for a 
datatype, although it could be easily extended to add the kind, for 
example. We only store the name of a selector. For a constructor, we 
also store its fixity and mark if it has fields. This last information is 
not strictly necessary, as it can be inferred by looking for non-empty 
selNames, but it simplifies some generic function definitions. The 
datatypes Fixity and Associativity are unsurprising: 

data Fixity = Prefix | Infix Associativity hit 

data Associativity = LeftAssociative \ RightAssociative 
I NotAssociative 

We provide default definitions for conFixity and conlsRecord to 
simplify instantiation for prefix constructors that do not use record 
notation^ 

Finally, we tie the meta-information to the representation: 

instance (Datatype 7) => Datatype (Mj D 7 <j> p) where 

datatypeName = datatypeName o unMeta 
moduleName = moduleName o unMeta 

instance (Constructor 7) => Constructor (Mj C 7 (j> p) where 
conName = conName o unMeta 

instance (Selector 7) => Selector (Mj S y<p p) where 
selName = selName o unMeta 

unMeta:: Mi iy§p->y 
unMeta = J_ 

Function unMeta operates at the type-level only, so it does not need 
an implementation. We provide more details in |Section 4.5| and the 
examples later in |Section 2.4| and |Section 3.6| also clarify how we 
use these classes. 

Note that we could encode the meta information as an extra 
argument to Mf. 

data Mi iy<j> p = Mj Meta (<p p) 
data Meta = Meta String Fixity . . . 

However, with this encoding we have trouble writing generic pro- 
ducers, since when we are producing an Mj we have to produce 
a Meta for which we have no information. With the above repre- 
sentation we avoid this problem by using type-classes to fill in the 
right information for us. See |Section 3.5| for an example of how this 
works. 



3 We also provide an empty default selName because all constructor argu- 
ments will be wrapped in an S;, independently of using record notation or 
not. We omit this in the example representations of this section for space 
reasons, but it becomes clear inlSection 41 



2.3 A generic view on data 

We obtain a generic view on data by defining an embedding- 
projection pair between a datatype and its type representation. We 
use the following classes for this purpose: 

class Representableo a T where 
fromo :: a — > % % 
to 0 ::TX^a 

class Representablej (j) % where 
front] ::(j) p — > T p 
toj :: T p — > (j> p 

We use T to encode the representation of a standard type. Since 1 is 
built from representation types, it is functorial. In Representablej, 
we encode types of kind * — > *, so we have the parameter p. In 
Representableo there is no parameter, so we invent a variable % 
which is never used. 

All types need to have an instance of Representableo- Types of 
kind * — > * also need an instance of Representablej. This sepa- 
ration is necessary because some generic functions (like finap or 
traverse) require explicit abstraction from a single type parame- 
ter, whereas others (like show or enum) do not. Given the different 
kinds involved, it is unavoidable to have two type classes for this 
representation. Note, however, that we have a single set of repre- 
sentation types (apart from the duplication for tagging recursion 
and parameters). 

Avoiding extensions Since we want to avoid using advanced 
Haskell extensions such as type families ( |Schrijvers et al. 20081 
or functional dependencies (Jones 2000), we use a simple multi- 
parameter type class for embedding-projection pairs. In fact, x is 
uniquely determined by a (and <j>). We could encode the represen- 
tation type more naturally with a type family: 

class Representableo a where 
type Repo a :: ★ — » * 
fromo a —* Repo OC % 
too ::Rep 0 ax^ a 

Since type families and functional dependencies are not yet part 
of any Haskell standard, we do not use them. Instead, we use 
multi-parameter type classes, and solve the ambiguities that arise 
by coercing with asTypeOf. 

2.4 Example representations 

We now show how to represent some standard datatypes. Note 
that all the code in this section is automatically generated by the 
compiler, as described in |Section~4] 

Representing Exp. The meta-information for datatype Exp looks 
as follows: 

data %Exp 

data $ Const Exp 
data %Plus Exp 

instance Datatype %Exp where 

moduleName _= "ModuleName" 
datatypeName _ = "Exp" 

instance Constructor %ConstExp where conName _ = "Const" 
instance Constructor %Plus£xp where conName _ = "Plus" 

In moduleName, "ModuleName" is the name of the module where 
Exp lives. The particular datatypes we use for representing the 
meta-information at the type-level are not needed for defining 
generic functions, so they are not visible to the user. In this pa- 
per, we prefix them with a $. 

The type representation ties the meta-information to the sum- 
of-products representation of Exp: 



type Rep^ p = 

Dj %Exp ( C] $ConstExp (Reco Int) 

+ C] %PlusExp {Reco Exp x Recg Exp)) 

Note that the representation is shallow: at the recursive occurrences 
we use Exp, and not Rep^ xp . 

The embedding-projection pair implements the isomorphism 
between Exp and Rep^ xp : 

instance Representableo Exp Rep^ p where 
fromo {Const n) = M, (L, (M, (K, n))) 
from 0 (Plus e e') = M,(R, (M, (K, e x K, e'))) 

too (Mi (L, (M, (Ki «)))) = Const n 

too (Mi (R, (Mi (K, ex K] e')))) = Plus e e' 

Here it is clear that fromo an d to 0 are inverses: the pattern of fromo 
is the same as the expression in too, an d vice-versa. 

Representing lists. The representation for a type of kind * — > * 
requires an instance for both Representable / and Representableo- 
For lists 

data List p = Nil \ Cons p (List p) deriving (Show, Encode) 

we generate the following code: 

type Rep^ st p = 

D] $List ( C] $Nil Lis , U] 

+ C] $Consii s t (Paro p x Reco (List p))) 

instance Representableo (List p) (Rep^"" p) where 
fromo Nil = M, (L, (Mi U,)) 

fromo (Cons ht)=M, (R, (Mi (K, h x K, tj)) 

to 0 (M,(L 1 (M,U 1 ))) =Nil 

to 0 (M; (Ri (Mj (Ki h x K, t)))) = Cons h t 

We omit the definitions for the meta-information, which are similar 
to the previous example. We use Paro to tag the parameter p, as we 
view lists as a kind datatype for Representableo- This is different 
in the Representable i instance: 

type Rep^"' =D, SList ( Ci $Nil List Ui 

+ C] %Consu st (Pari x R ec l List)) 

instance Representable] List Rep\"" where 
from! Nil = Mi (L, (M, U,)) 

fromi (Cons ht) =Mi (Ri (Mi (Pari h x Reci t))) 

toi (Mi (Li (Mi U,))) =Nil 

toi (Mi (Ri (Mi (Pari h x Reci ?)))) = Cons h t 

We treat parameters and recursion differently in Rep^"" and Rep^' st . 
In RepQ ,st we use Paro and Reco for mere tagging; in Rep^' sl we use 
Pari and Rec; instead, which store the parameter and the recursive 
occurrence of a type constructor, respectively. We will see later 
when defining generic functions l |Section 3} how these are used. 

Representing type composition. We now present a larger exam- 
ple, involving more complex datatypes, to show the expressiveness 
of our approach. Datatype Expr represents abstract syntax trees of 
a small language: 

inflxr 6 * 

data Expr p = Const Int 

| Expr p * Expr p 

I V ar E.xpr {unVarv.Var p } 

| Let [Declp] (Expr p) 

data Decl p = Decl (Var p) (Expr p) 



data Var p = Var p \ Var L (Var [p]) 

Note that Expr makes use of an infix constructor (*), has a selector 
(unVar), and uses lists in Let. Datatype Var is nested, since in the 
Vari constructor Var is called with [p]. These oddities are present 
only for illustrating how our approach represents them. We show 
only the essentials of the encoding of this set of mutually recursive 
datatypes, starting with the meta-information: 

data %TimesEx pr 
data $Var ExprExpr 

data SUnVar 

instance Constructor %Times£ X pr where 
conName _ = " * " 
conFixity _ = Infix Right Associative 6 

instance Constructor $VarExpr Expr where 
conName _="Var_Expr" 
conlsRecord _ = True 

instance Selector %UnVar where selName _ = "unVar" 

We have to store the fixity of the * constructor, and also the fact that 
VarExpr has a record. We store its name in the instance for Selector, 
and tie the meta-information to the representation: 

type Rep\ xpr = Di %Expr 

( ( C] $Const£xpr (R ec 0 Int) 

+ C] %TimesE X pr (Reci Expr x Rec; Expr)) 
+ ( Ci $Var ExprExpr (Si SUnVar {Rec, Var)) 

+ C, %Let Ex p r (({] o Rec, Decl) x Rec, Expr))) 

In Rep^ xpr we see the use of S, . Also interesting is the represen- 
tation of the Let constructor: the list datatype is applied not to the 
parameter p but to Decl p, so we use composition to denote this. 
Note also that we are using a balanced encoding for the sums (and 
also for the products). This improves the performance of the type- 
checker, and makes generic encoding more space-efficient, for in- 
stance. 

We omit the representation for Decl. For Var we use composi- 
tion again: 

typeRepf"' = D] $Var 

( C] SVarvar Pari 

+ C] $Var LVar (Vara Rec, [])) 

In the Var, constructor, Var is applied to [p], We represent this as 
a composition with Rec, [ ] . 

When we use composition, the embedding-projection pairs be- 
come slightly more complicated: 

instance Representable, Expr Rep^ xpr where 
from, (Const i) = M, (L, (L, (M, (K, i)))) 
from, (e, * £2) = M, (L; (R, (M, (Rec, e, x Rec, e2)))) 
from, (Var Ex p r v)=M, (Ri (L, (M, (M, (Rec, v))))) 
from, (Let d e) = 

M; (R, (R] (Mi (Comp, (fmapReci d) x Reci «)))) 
to, (M, (L, (L, (Mj (Ki ())))) = Const i 

toi (Mi (Li (R, (M, (Rec, e, x Rec, e2))))) =e; * e2 
toi (Mi (R, (L, (M, (M, (Rec, v)))))) = Var Ex pr v 

toi (Mi (R, (R, (M, (Comp, d x Rec, e))))) = 

Let (finap unRec , d) e 

We need to use fmap to apply the Rec, constructor inside the lists. 
In this case we could use map instead, but in general we require the 
first argument to o to have a Functor instance so we can use. fmap. 
In to] we need to convert back, this time mapping unReci. 



For Var, the embedding-projection pair is similar: 

instance Representable] Var Rep^ ar where 
fromj (Varx) = M] (Lj (Mj (Par] x))) 
fromj (Var^xs) =M] (Rj (Mj (Compi (fmap Rec j xs)))) 

toj (Mj (Li (Mi (Pari *)))) = Varx 

toj (Mj (Rj (Mj (Compi xs)))) = Vari (fmap unRec / xs) 

Note that composition is used both in the representation for the 
first argument of constructor Let (of type [Dec! p ] ) and in the nested 
recursion of Vari (of type Var [p]). In both cases, we have a recur- 
sive occurrence of a parametrized datatype where the parameter is 
not just the variable p. Recall our definition of composition: 

data (o) tj> iff p = Compi ((j) (iff p)) 

The type (j) is applied not to p, but to the result of applying \ff to p. 
This is why we use o when the recursive argument to a datatype is 
not p, like in [Decl p] and Var [p]. When it is p, we can simply 
use Rec i . 

We have seen how to represent many features of Haskell 
datatypes in our approach. We give a detailed discussion of the 
supported datatypes in |Section 7.1| 

3. Generic functions 

In this section we show how to define type classes with derivable 
functions. 

3.1 Generic function definition 

Function encode is a method of a type-class: 
data Bit = 0\1 

class Encode a where 
encode:: a —> [Bit] 

We cannot provide instances of Encode for our representation 
types, as those have kind — > , and Encode expects a parameter of 
kind *. We therefore define a helper class, this time parametrized 
over a variable of kind — > : 

class Encode / tj) where 
encode] :: 0 % — > [Bit] 

For constructors without arguments we return the empty list, as 
there is nothing to encode. Meta-information is discarded: 

instance Encode] Uj where 
encode i _ = [ ] 

instance (Encode j tf>) => Encode; (Mj l ytj>) where 
encode] (Mj a) = encode] a 

For a value of a sum type we produce a single bit to record the 
choice. For products we concatenate the encoding of each element: 

instance (Encode] <p, Encode/ \ff) =£> Encode] (tf) + iff) where 
encode] (Lj a) = 0: encode] a 
encode ] (Rj a) = 1 : encode] a 

instance (Encode; 0, Encode; \ff) Encode; (tj) x \ff) where 
encode; (a x b) = encode; a ^encode; b 

It remains to encode constants. Since constant types have kind , 
we resort to Encode: 

instance (Encode tf>) => Encode; (K; i tf>) where 
encode; (K; a) = encode a 

Note that while the instances for the representation types are given 
for the Encode; class, only the Encode class is exported and al- 
lowed to be derived. This is because its type is more general, and 



because we need a two-level approach to deal with recursion: for 
the K; instance, we recursively call encode instead of encode;. Re- 
call our representation for Exp (simplified and with type synonyms 
expanded): 

type Repl xp = K; R Int + K; R Exp x K; R Exp 

Since Int and Exp appear as arguments to K;, and our instance 
of Encode; for K; l tj) requires an instance of Encode tj), we need 
instances of Encode for Int and for Exp. We deal with Int in the next 
section, and Exp in |Section 3 .3 1 Finally, note that we do not need 
Encode; instances for Rec;, Par; or (o). These are only required 
for generic functions which make use of the Representable; class. 
We will see an example in |Section 3.4| 

3.2 Base types 

We have to provide the instances of Encode for the base types: 

instance Encode Int where encode = . . . 
instance Encode Char where encode = ... 

Since Encode is exported, a user can also provide additional base 
type instances, or ad-hoc instances (types for which the required 
implementation is different from the derived generic behavior). 

3.3 Default definition 

We miss an instance of Encode for Exp. Instances of generic func- 
tions for representable types rely on the embedding-projection 
pair to convert from/to the type representation and then apply the 
generic function: 

encode Default ■■ (Representable o a T, Encode; t) 

=> T x -> « -> [Bit] 
encode Default re P x — encode ; ( (fromo x) 'asTypeOf rep) 

Function encoderiefault te U s me compiler what to fill in for the 
instance of each of the derived types. Because we do not want 
to use functional dependencies for portability reasons, we pass 
the representation type explicitly to function encode Default- This 
function uses the representation type to coerce the result type of 
fromo with asTypeOf. This slight complication is a small price to 
pay for extended portability. 

Now we can show the instance of Encode for Exp and List: 

instance Encode Exp where 

encode = encode De fauit (-L ::Rep E ^ p %) 
instance (Encode p) Encode (List p) where 

encode = encode De f a ult (-L ::Rep^"" p %) 

Both instances look similar and trivial. However, the instance for 
List requires scoped type variables to type-check. We can avoid the 
need for scoped type variables if we create an auxiliary local func- 
tion encode i, sl with the same type and behavior of encodeDefault'- 

instance (Encode p) => Encode (List p) where 
encode = encoden sl _L where 

encodeust (Encode p) =>• Rep^ 1 " p % — > List p — > [Bit] 
encodeust — en codeDefault 

Here, the local function encoders! encodes in its type the corre- 
spondence between the type List p and its representation Rep^' st p. 
Its type signature is required, but can easily be obtained from the 
type of encodeDefault by replacing the type variables a and T with 
the concrete types for this instance. 

For completeness, we give the instance for Exp in the same 
fashion: 

instance Encode Exp where 
encode = encode^, _L where 



encode Exp y.RepQ % — » Exp — > [B/f] 
encode Exp = encode De f auh 

It might seem strange that we choose not to use Haskell's built- 
in functionality for default definitions for class methods. Unfortu- 
nately we cannot use default methods, for two reasons: 

1. Since we avoid using type families and functional dependen- 
cies, we need to explicitly pass the representation type as an 
argument to encode Default- 

2. A default case would force us to move the Representableo a T 
and Encode i x class constraints to the Encode class, possibly 
preventing ad-hoc instances for non-representable types and 
exposing Encode j to the user. 

However, if the compiler is to generate instances for Exp and 
other representable datatypes automatically, how does it know 
which function to use as default? The alternative to standard 
Haskell default methods is to use a naming convention for this 
function (like appending Default to the class function name, as in 
our example). It is more reliable to use a pragma: 

{— # DERIVABLE Encode encode encode Default # — } 

This pragma takes three arguments, which represent (respectively): 

1 . The class which we are defining as derivable 

2. The method of the class which is generic (and therefore needs 
a default definition) 

3. The name of the function which serves as a default definition 

Such a pragma also has the advantage of indicating derivability 
for a particular class. We could use a keyword such as derivable to 
signal that a class is allowed to be derived: 

derivable class Encode a where . . . 

However, by using a pragma instead (as described above) we ensure 
more portability, as compilers without support for our derivable 
type classes can still compile the code. 

Since a class can have multiple generic methods, multiple prag- 
mas can be used for this purpose. Note, however, that a derivable 
class can only have non-generic methods if there is a default def- 
inition for these, as otherwise we have no means for implement- 
ing the non-generic methods. Alternatively, we could treat generic 
methods as default methods, filling in the generic definition auto- 
matically if the user does not give a definition. This would allow 
classes to have normal, generic, and default methods. However, it 
would complicate the code generation mechanism. 

3.4 Generic map 

In this subsection we define the generic map function finap, which 
implements the Prelude's fmap. Function fmap requires access to 
the parameter in the representation type. As before, we export a 
single class together with an internal class where we define the 
generic instances: 

class Functor 0 where 
fmap :: (p — > a) — » <j) p — > (j) a 

class Functorj (f> where 
fmapi :: (p — > a) — > <f> p — » (j) a 

Unlike in Encode, the type arguments to Functor and Functorj 
have the same kind, so we do not really need two classes. How- 
ever, for consistency, we use the same style as for kind generic 
functions. 

We apply the argument function in the parameter case: 



instance Functorj Pari where 
fmap if {Parj a) = Pari if a ) 

Unit and constant values do not change, as there is nothing we can 
map over. We apply fmapi recursively to meta-information, sums 
and products: 

instance Functor -j U j where 

fmapifUi =Ui 
instance Functor j (Kj l y) where 

fmap; f (K] a) = Kj a 

instance (Functor] 0) => Functor; (Mj l ytp) where 
fmapjf (Mj a) = Mj (fmap if a) 

instance (Functorj 0, Functorj iff) Functorj (<j> + iff) where 
fmapjf(Lj a) = Lj (fmapj f a) 
fmapjf(Rj a) = Rj (fmap j fa) 

instance (Functorj (j), Functorj iff) Functorj ((f) x iff) where 
fmap j f (a x b) = finap j f a x fmap jfb 

If we find a recursive occurrence of a functorial type, we call fmap 
again, to tie the recursive knot: 

instance (Functor 0) => Functorj (Recj 0) where 
fmapj f (Recj a) = Recj (fmapf a) 

The remaining case is composition: 

instance (Functor (j), Functorj iff) Functorj (<j> o iff) where 
fmapjf (Compj x) = Compj (fmap (fmapjf) x) 

Recall that we require the first argument of (o) to be a user-defined 
datatype, and the second to be a representation type. Therefore, we 
use finap j for the inner mapping (as it will map over a represen- 
tation type) but finap for the outer mapping (as it will require an 
embedding-projection pair). This is the general structure of the in- 
stance of (o) for a generic function. 
Finally, we define the default method: 

{— # DERIVABLE Functor finap fmap Default # — } 
.finap Default (Representable j (j) T, Functorj %) 

^>Tp~>(p—>a)~^<f)p—><l)a 
fmaPDefauU repf x = toj (fmapjf (fromj x 'asTypeOf rep)) 

Now Functor can be derived for user-defined datatypes. The usual 
restrictions apply: only types with at least one type parameter and 
whose last type argument is of kind can derive Functor. The 
compiler derives the following instance for List: 

instance Functor List where 
fmap =fmap Ust (_L ::Rep^' st p) where 

finap Ust ::Rep\' s ' p — + (p — * a) — * List p — * List a 

ftnaPUst =f ma PDefault 

Note that the instance Functor List also guarantees that we can use 
List as the first argument to (o), as the embedding-projection pairs 
for such compositions need to use fmap. 

The instances derived for Expr, Decl, and Var are similar. 

3.5 Generic empty 

We can also easily express generic producers: functions which 
produce data. We will illustrate this with function empty, which 
produces a single value of a given type: 

class Empty a where empty : : a 

This function is perhaps the simplest generic producer, as it con- 
sumes no data. It relies only on the structure of the datatype to pro- 
duce values. Other examples of generic producers are the methods 
in Read and the Arbitrary class from QuickCheck, and binary's 
get. As usual, we define an auxiliary type class: 



class Empty i <j> where 
empty' :: (j) % 

Most instances of Empty j are straightforward: 

instance Empty i Uj where 
empty' = Uj 

instance {Empty j <j>) Empty] (Mj i y<j>) where 
empty' = Mj empty 1 

instance (Empty j (j), Empty 1 y) => Empty 1 (<j) x \j/) where 
empty' = empty' x empty 1 

instance (Empty <j>) => Empty j (Kj l <f>) where 
empty' = Kj empty 

For units we can only produce Uj. Meta-information is produced 
with M], and since we encode the meta-information using type 
classes (instead of using extra arguments to Mj) we do not have to 
use _L here. An empty product is the product of empty components, 
and for Kj we recursively call empty. The only interesting choice 
is for the sum type: 

instance (Empty j <(>)=> Empty j (0 + 1//") where 
empty' = Lj empty' 

In a sum, we always take the leftmost constructor for the empty 
value. Since the leftmost constructor might be recursive, function 
empty might not terminate. More complex implementations can 
look ahead to spot recursion, or choose alternative constructors af- 
ter recursive calls, for instance. Note also the similarity between our 
Empty class and Haskell's Bounded: if we were defining minBound 
and maxBound generically, we could choose Lj for minBound and 
Rj for maxBound. This way we would preserve the semantics 
for derived Bounded instances, as defined by |Peyton Jones et al.| 
( 2003 ), while at the same time lifting the restrictions on types that 
can derive Bounded. Alternatively, to keep the Haskell 98 behavior, 
we could give no instance for x , as enumeration types will not have 
a product in their representations. 

The default method simply applies too to empty': 

{— # DERIVABLE Empty empty empty De j au[r #—} 
empty De f au i t :: (Representableo (X T, Empty j t) 

empty De f au i t rep = too (empty 1 'asTypeOf' rep) 

Now the compiler can produce instances such as: 

instance Empty Exp where 
empty = empty Exp _L where 

empty Exp :: Repf p % -> Exp 
empty Exp = empty Defauh 

instance (Empty p) => Empty (List p) where 
empty = empty List _L where 

empty List (Empty p) =^ Rep^ is ' p%^ List p 
empty List = empty Default 

Instances for other types are similar. 
3.6 Generic show 

To illustrate the use of constructor and selector labels, we define 
the shows function generically: 

class Show a where 
shows : : a — > ShowS 
show :: a — > String 
show x = shows x " " 

We define a helper class Show;, with shows / as the only method. 
For each representation type there is an instance of Showj. The 



extra Bool argument will be explained later. Datatype meta-infor- 
mation and sums are ignored. For units we have nothing to show, 
and for constants we call shows recursively: 

class Showj <j> where 

shows 1 y.Bool —> (j) % ~ > ShowS 

instance (Showi <j>) =£> Showj (Dj y 0) where 

shows] b (Mj a) = shows 1 b a 

instance (Show 2 <S>,Showj y) => Showj (0 + y) where 
showsj b (Lj a) = showsj b a 
shows j b (Rj a) = shows j b a 

instance Showj U 1 where 
shows j _ U; —id 

instance (Show <j>) => Show; (A*; l tf>) where 
showsj _ (K] a) = shows a 

The most interesting instances are for the meta-information of a 
constructor and a selector. For simplicity, we always place paren- 
theses around a constructor and ignore infix operators. We do dis- 
play a labeled constructor with record notation. At the constructor 
level, we use conlsRecord to decide if we print surrounding brack- 
ets or not. We use the Bool argument to shows j to encode that we 
are inside a labeled field, as we will need this for the product case: 

instance (Showj (j), Constructor 7) => Showi (Mj C y 0) where 
showsj _c@(Mj a) = 

showString " (" o showString (conName c) 
o showString " " 

0 wrapRecord 

(shows j (conlsRecord c) ao showString ")") 
where 

wrapRecord :: ShowS — > ShowS 

wrapRecord s \ conlsRecord c — showString " { "os 

o showString " }■" 
wrapRecord s \ otherwise = s 

For a selector, we print its label (as long as it is not empty), followed 
by an " = " and the value. In the product, we use the Bool to decide 
if we print a space (unlabeled constructors) or a comma: 

instance (Showj (f), Selector y) => Showj (Mj S y (f>) where 
shows] b s@(M] a) 

1 null (selName s) = shows j b a 

I otherwise = showString (selName s) 

o showString " = " o shows j b a 

instance (Showj (j>, Showj 1//) => Showj (<j) x y) where 
showsj b (a x c) = showsj ba 

o showString (if b then " , " else " " ) 

o shows j b c 

Finally, we provide the default: 

{-# DERIVABLE Show shows shows Default #— } 
showsj) e f au i t :: (Representableo OL T,Showj l) 

=> T % — > « — > ShowS 
showsj) e f m< i t rep x = showsj False (fromo x 'asTypeOf rep) 

We have shown how to use meta-information to define a generic 
show function. If we additionally account for infix constructors 
and operator precedence for avoiding unnecessary parentheses, 
we obtain a formal specification of how show behaves on every 
Haskell 98 datatype. 



4. Compiler support 

We now describe in detail the required compiler support for our 
generic deriving mechanism. 

We start by defining two predicates on types, isRepo (<j>) 
and isRepi ((j>), which hold if (j> can be made an instance of 
Representableo and Representablej , respectively. The statement 
isRepo ((/>) holds if (/> is any of the following: 

1. A regular Haskell 98 datatype without context 

2. An empty datatype 

3. A type variable of kind 

We also require that for every type iff that appears as an argument 
to a constructor of (j), isRepg (t//) holds. <f> cannot use existential 
quantification, type equalities or any other extensions. 

The statement isRepi ((j>) holds if the following conditions both 
hold: 



1. isRepo (<j>) 

2. <h is of kind 



or A- 



— > *, for any kind 

Note that isRepo holds for all the types o f|Section 2.4| while isRepi 
holds for List, Expr, Decl, and Var. 

Furthermore, we define the predicate ground (<p) to deter- 
mine whether or not a datatype has type variables. For instance, 
ground ([hit]) holds, but ground ([oc]) not. Finally, we assume the 
existence of an indexed fresh variable generator fresh which 

binds /?' to a unique fresh variable. 

For the remainder of this section, we consider a user-defined 
datatype 



data Dai ...a„ = Con\ {/] : 



Pv 



A' ■■pi 1 } 



I Con m { l}„ ::pj n ,..., & m : : p%' } 

with n type parameters, m constructors and possibly labeled param- 
eter ^ of type p. at position j of constructor Corn. 

4.1 Type representation (kind ) 

In |Figure l] we show how we generate type representations for 
a datatype D satisfying isRepo (£>). We generate a number of 
empty datatypes which we use in the meta-information: one for the 
datatype, one for each constructor and one for each argument to a 
constructor. 

The type representation is a type synonym (Rep®) with as many 
type variables as D. It is a wrapped sum of wrapped products: the 
wrapping encodes the meta-information. We wrap all arguments to 
constructors, even if the constructor is not a record. Since we use 
a balanced sum (resp. product) encoding, a generic function can 
use the meta-information to find out when the sum (resp. product) 
structure ends, which is when we reach Cj (resp. Sj). Each argu- 
ment is tagged with Pcivq if it is one of the type variables, or Recg 
if it is anything else (type application or a concrete datatype). 

4.2 Representableo instance 

The instance Representableo R e Pu is defined in Figure 2 as in- 
troduced in Section [2] The patterns of the fromo function are the 
constructors of the datatype applied to fresh variables. The same 
patterns become expressions in function too- The patterns of too 
are also the same as the expressions of fromo, and they represent 
the different values of a balanced sum of balanced products, prop- 
erly wrapped to account for the meta-information. Note that, for 
Representableo, the functions tuple and wrap do not behave dif- 
ferently depending on whether we are in fromo or too, so f° r these 
declarations the dir argument is not needed. Similarly, the wrap 



function could have been inlined. These definitions will be refined 
in lSection 4.41 

4.3 Type representation (kind * — » *) 

See |Figure 3] for the type representation of type constructors. 
We keep the sum-of-products structure and meta-information un- 
changed. At the arguments, however, we can use Paro, Pari, Reco, 
Rec], or composition. We use Pari f° r the type variable a, and 
Parg f° r other type variables of kind . A recursive occurrence of 
a type containing a„ is marked with Recj. A recursive occurrence 
of a type with no type variables is marked with Reco, as there is 
no variable to abstract from. Finally, for a recursive occurrence of 
a type which contains something else than a„ we use composition, 
and recursively analyze the contained type. 

4.4 Representable i instance 

The definition of the embedding-projection pair for kind * — > * 
datatypes, shown in |Figure~4| reflects the more complicated type 
representation. The patterns are unchanged. However, the expres- 
sions in toi need some additional unwrapping. This is encoded in 
var and unwC: an application to a type variable other than a„ has 
been encoded as a composition, so we need to unwrap the elements 
of the contained type. We use fmap for this purpose: since we re - 
quire isRepi ((j>), we know that we can use fmap (see Section 3A\ . 
The user should always derive Functor for container types, as these 
can appear to the left of a composition. 

Unwrapping is dual to wrapping: we use Pari f° r the type pa- 
rameter a„, Rec i for containers of a„, Ki for other type parameters 
and ground types, and composition for application to types other 
than a„. Considering composition, in to; we generate only Comp; 
applied to a fresh variable, as this is a pattern; the necessary un- 
wrapping of the contained elements is performed in the right-hand 
side expression. In from ; the contained elements are tagged prop- 
erly: this is performed by wC«. 

4.5 Meta-information 

We generate three meta-information instances. For datatypes, we 
generate 

instance Datatype $D where 
moduleName _ = mName 
datatypeName _ = dName , 

where dName is a String with the unqualified name of datatype D 
and mName is a String with the name of the module in which D is 
defined. 

For constructors, we generate 

instance Constructor $Co/i; where 
conName _ = name 
{ conFixity _= fixity} 
{ conlsRecord _ = True } , 

where i £ l..m, and name is the unqualified name of constructor 
Coiii. The braces around conFixity indicate that this method is 
only defined if Con; is an infix constructor. In that case, fixity 
is Infix assoc prio, where prio is an integer denoting the priority 
of Coiii, and assoc is one of LeftAssociative, RightAssociative, or 
NotAssociative. These are derived from the declaration of Con, as 
an infix constructor. The braces around conlsRecord indicate that 
this method is only defined if Coin uses record notation. 
For all i £ {l..m}, we generate 

instance Selector %L 1 j {where selName _=/■}, 

where j 6 {l..o,}. The brackets indicate that the instance is only 
given a body if Con, uses record notation. Otherwise, the default 
implementation for selName is used, i.e. const " ". 



data $D 

data %Con\ 

data %Con m 
data %L\ 

data $C' 
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Figure 1. Code generation for the type representation (kind ) 



instance Representableg (D aj ... a n ) (Rep® aj ...a„) where { 



fromo pat]™" = exp^' om ; 

from 0 pat£ om = exp£', om ; 

inji,m x | m = 0 = _L 
| m = 1 = x 
| i < ml = Lj (inj, V)1 - x) 
\i>m! =R, (inj ; / ,,„_„,/ x) 
where m' = \m / 2 J 

i =l;/2J 



to 0 pat'" = exp'j 0 ; 
to 0 pat;° = exp«;} 



expj° = patf™" = Conj (fresh p/) . . . (fresh p°' ) 
expf m = patf = M 7 (inj,- m (M 7 (tuple, (pj . . .p?)))) 



tuplef^...p°')|o/ = 0 =M 7 t/ 7 

\ 0i =j = Mj (wrap dj> (fresh pj)) 
| otherwise = (tuplef r (p? . . .pf)) x (tuplef r (pf +1 . . .pf )) 
where A; = |_o; / 2J 



Figure 2. Code generation for the RepresentableQ instance 
type Repf ct; . . . a„_ 7 = fl 7 $D (I^ (C; $C™ ; (YlJZx (Si $L\ (argpj))))) 
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3 ke{l..n-\}-P l i = a k =Par 0 p' i 
p'i = a„ = Pari 

p t = <j) a„ A isRepi (<j>) = Reci p(- 

pj- = <p j8 A isRepi ((p) A -> ground (p) = <f> o arg /3 
otherwise = Reco p J i 

Figure 3. Code generation for the type representation (kind * — > *) 
instance Representahlej (Da;... «,,_/) (/?epf a 7 . . . a„_ 7 ) where { expf = Coiy (var p* ) . .. (var pf) 

j. J'rom from .i n to 

frorm pafj ^exp 7 , ; to 7 patf = expf; varpj. | ^. = ^ a A a ^ a„ 

: : A isRepi (<p) =fmap unwC a (fresh pj) 

/ rom/ pat{;r=exp£ om ; to 7 pat£ = exp£; } I otherwise = fresh pj 



patj'"", expj m , inj, m x, and tuplef !r (pi . . .p m ) as in Figure 2 (but using the new wrap d ' r x) 



wrap*'' p' l \p l i = a„ = Pari (fresh p\) 

\p l i = (j)a„A isRepi ((j>) = Rec! (fresh p 1 ^ 
\^ke{i..n}-P i i = a k =Kj (freshpj) 

|p( = *OA-isRepi(0)=Jr i (ftwh^) wC a |«^a„ 
|p- = 0 a Adir=from = Compj (finapvrC a (fresh pj-)) | ground (a) 



otherwise 



Compi (fresh p') 



unwCa | a = a„ = unParj 

\ a = tj) a„ A isRepi (0) = unRecj 
\ a = tj) j5 A ground Q3) = unRecQ 
| a = 0 /3 A isRepi (0) =fmap unwCp o unCompj 

= Par; 
= Ki 



a = <j> a n A isRep! (0) = ifec 7 

a = <j> p A isRepi (0) = Compi o (/map wCc 



Figure 4. Code generation for the Representahlej instance 



4.6 Default instances 

The instances of a class representing the different cases of a generic 
function on representation types present somewhat more of a chal- 
lenge because they refer to a specific function defined by the 
generic programmer (in our running example encodeDefault). The 
compiler knows which function to use due to the DEFAULT pragma 
(Section 3.3j >. 

After the default function has been determined, the only other 
concern is passing the explicit type representation, encoded as a 
typed ±. 

4.6.1 Generic functions on Representableo 

For each generic function/ that is a method of the type class F, and 
for every datatype D with type arguments Uj .. .a„ and associated 
representation type Rep D <X\ . . .a n %, the compiler generates: 

instance (C.) => F (D aj ... a„) where 
/ =f D ± where 

f D :: (C.) => Repfi Cd-.-OnX^P 
}D =f Default 

The type /3 is the type of / specialized to D, and % is a fresh 
type variable. The context C is the same in the instance head and 
in function /q. The exact context generated depends on the way 
the user specified the deriving. If deriving F was attached to the 
datatype, we generate a context F 0C\,. .. ,F a„, where ~a is the 
variable a applied to enough fresh type variables to achieve full 
saturation. This approach gives the correct behavior for Haskell 98 
derivable classes like Show. In general, however, it is not correct: 
we cannot assume that we require F a, for all i 6 { 1 . .«}: generic 
children, for instance, does not require any constraints, as it is 
not a recursive function. Worse even, we might require constraints 
other than these, as a generic function can use other functions, for 
instance. 

To avoid these problems we can use the standalone deriving 
extension. If we have a standalone deriving 

deriving instance (C. . .) => F (D aj . . . a n ) 

we can simply use this context for the instance. In general, however, 
the compiler should be able to infer the right context by analyzing 
the context of the generic function and the structure of the datatype. 

4.6.2 Generic functions on Representable j 

For each generic function/ that is a method of the type class F, and 
for every datatype D with type arguments aj ... a„ and associated 
representation type Rep® CC] ...a„, the compiler generates: 

instance (C ...)=> F (D (Xi ... a„-i ) where 
/ =fo -1 where 

f D ::(C...)^Rep D a ] ...a n ->p 

}D =f Default 

The type ft is the type of / specialized to D (in other words, 
/:: jS). This code is almost the same as that for generic functions 
on Representableo, with a small exception for handling the last 
type variable (a„). The context can be copied from the standalone 
deriving, if one was used, or just inferred by the compiler. 

4.7 UHC specifics 

We have a prototype implementation of our deriving mechanism 
in UHC. Although generating the required datatypes and instances 
is straightforward, we have to resolve some subtle issues. In our 
implementation, the following issues arose: 

Which stage of the compiler pipeline generates the datatypes and 
instances? Ideally, all deriving-related code is generated as early 



as possible, for example during desugaring, so later compiler stages 
can type check the generated code. However, the generation needs 
kind information of types and classes, which is only available af- 
ter kind checking. In UHC, the datatypes and instances are directly 
generated as intermediate Core, directed by kind information, and 
only the derived instances are intertwined with type checking and 
context reduction because of the use of the default deriving func- 
tions. 

Use of fniap. The generation of embedding-projection pairs for 
types with composition requires frnap, which in turn requires the 
context reduction machinery to resolve overloading. This compli- 
cates the interaction with the compiler pipeline, because the gen- 
eration becomes not only kind-directed, but also context reduction 
proof-directed. However, all occurrences of fmap are applied to the 
identity function id, because wrappers like Par] are defined as new- 
types. In UHC, the use of context reduction is avoided assuming the 
equality fmap id = id. 

Code size. Some quick measurements show a 10% increase in 
the size of the generated code. Although language pragmas like 
GenericDeriving and NoGenericDeriving could selectively switch 
this feature on or off, this would defeat the purpose of generic- 
ity. Once turned off for a datatype, no Representableo are gener- 
ated, and no generic instances can be defined anymore. Instead, 
later transformations should prune unused code. These issues need 
further investigation. 

Bootstrapping. As soon as a user defines a datatype, code gen- 
eration generates the supporting datatypes. Such datatypes (e.g. 
%Con\) and the datatypes used by supporting datatypes (e.g. Bool, 
used in the return type of conlsRecord) are mutually dependent, 
which is detected by binding group analysis. Each binding group 
type analysis must deal with mutually dependent datatypes. This 
also means that the supporting definitions must be available in the 
first module that contains a datatype. 

Interaction with desugaring. Currently, deriving clauses are just 
syntactic sugar for standalone deriving. After desugaring, we can- 
not decide to generate a Representableo or a Representable j in- 
stance because kind information is not available. Automatically 
generating the correct context for such an instance cannot be done 
either. To work around this limitation, we only accept deriving 
clauses for generic classes that use Representableo. Derivings for 
Representable j classes have to use standalone deriving syntax, 
since then we no longer need to infer a context, and can let the 
programmer provide the required context. 

5. Alternatives 

We have described how to implement a deriving mechanism that 
can be used to specify many datatype-generic functions in Haskell. 
There are other alternatives, of varying complexity and type-safety. 

5.1 Pre-processors 

The simplest, most powerful and least type safe alternative to 
our approach is to implement deriving by pre-processing the 
source file(s), analyzing the datatypes definitions and generating 
the required instances with a tool such as DrIFT (Winstan ley and| 
Meacham 2008 1. This requires no work from the compiler writer, 
but does not simplify the task of adding new derivable classes, as 
programming by generating strings is not very convenient. 

Staged meta-programming lies in between a pre-processor and 
an embedded datatype-generic representation. GHC supports Tem- 
plate Haskell ( S heard and Peyton Jones|2002| l, which has become 
a standard tool for obtaining reflection in Haskell. While Template 
Haskell provides possibly more flexibility than the purely library- 
based approach we describe, it imposes a significant hurdle on the 



compiler writer, who does not only have to implement a language 
for staged programming (if one does not yet exist for the com- 
piler, like in UHC), but also keep this complex component up-to- 
date with the rest of the compiler, as it evolves. As an example, 
Template Haskell support for GADTs and type families only ar- 
rived much later than the features themselves. Also, for the deriv- 
able class writer, using Template Haskell is more cumbersome and 
error-prone than writing a datatype-generic definition in Haskell it- 
self. 

For these reasons we think that our library-based approach, 
while having some limitations, has a good balance of expressive 
power, type safety, and the amount of implementation work re- 
quired. 

5.2 Generic programming libraries 

Another design choice we made was in the specific library approach 
to use. We have decided not to use any of the existing libraries but 
instead to develop yet another one. However, our library is merely a 
variant of existing libraries, from which it borrows many ideas. We 
see our representation as a mixture between regular (Van Noort 
et al. |2008) and instant -generics ( |Chakravarty et al.|2009) . We 
share the functorial view with regular; however, we abstract from 
a single type parameter, and not from the recursive occurrence. Our 
library can also be seen as instant-generics extended with a 
single type parameter. However, having one parameter allows us 
to deal with composition effectively, and we do not duplicate the 
representation for types without parameters. 

Since we wanted to avoid using GADTs, and we wanted an 
extensible approach, we had to exclude most of the other generic 
programming libraries. The only possible choice would have been 
EMGM (Oliv eira et al.| [2007l, which supports type parameters, is 
modular and does not require fancy extensions. However, EMGM 
duplicates the representation for higher arities, and encodes the 
representation of a type at the value level. We prefer encoding the 
representation only at the type level, as this has proven to allow for 
type-indexed datatypes (see |Section 7.2} . 

6. Related work 

The generic programming library we present shares many aspects 
with regular (Van Noort et al. |2008|> and instant-generics 
(Chakravarty et al. 2009). Clean ( Alimarine and Plasmeijer 2001 1 
has also integrated generic programming directly in the language. 
We think our approach is more lightweight: we express our generic 
functions almost entirely in Haskell and require only one small 
syntactic extension. On the other hand, the approach taken in Clean 
allows defining generic functions with polykinded types (Hinze 
20021, which means that the function bimap (see |Section 2. 1| >, for 
instance, can be defined. Not all Clean datatypes are supported: 
quantified types, for example, cannot derive generic functions. Our 
approach does not support all features of Haskell datatypes, but 
most common datatypes and generic functions are supported. 

An extension for derivable type classes similar to ours has 
been developed by |Hinze and Peyton Jones| ( |2001) in GHC. As 
in Clean, this extension requires special syntax for defining generic 
functions, which makes it harder to implement and maintain. In 
contrast, generic functions written in our approach are portable 
across different compilers. Furthermore, Hi nze and Peyton Jones| s 
approach cannot express functions such as fmap, as their type 
representation does not abstract over type variables. 

Rodriguez Yakushe v et al.| (2008 ) give criteria for comparing 
generic programming libraries. These criteria consider the library's 
use of types, and its expressiveness and usability. Regarding types, 
our library scores very good: we can represent regular, higher- 
kinded, nested, and mutually recursive datatypes. We can also ex- 
press subuniverses: generic functions are only applicable to types 



that derive the corresponding class. We only miss the ability to 
represent nested higher-kinded datatypes, as our representation ab- 
stracts only over a parameter of kind *. 

Regarding expressiveness, our library scores good for most cri- 
teria: we can abstract over type constructors, give ad-hoc definitions 
for datatypes, our approach is extensible, supports multiple generic 
arguments, represents the constructor names and can express con- 
sumers, transformers, and producers. We cannot express gmapQ in 
our approach, but our generic functions are still first-class: we can 
call generic map with generic show as argument, for instance. Ad- 
hoc definitions for constructors would be of the form: 

instance Show Exp where 

shows (Phis ej e2)= shows ej o showString " + " o shows e2 
shows x = shows Defau i, (_L ::Rep^ p %) x 

However, in our current implementation, Rep^ 1 ' is an internal type 
synonym not exposed to the user. Exposing it to the user would re- 
quire a naming convention. If UHC supported type families < )Schri-| 
jvers et al. 2008 ), Repg could be a visible type family, which would 
solve our problem for ad-hoc definitions of constructors. It would 
also remove the need for using asTypeOf in |Section 2.3| 

Regarding usability, our approach supports separate compila- 
tion, is highly portable, has automatic generation of its two rep- 
resentations, requires minimal work to instantiate and define a 
generic function, is implemented in a compiler and is easy to use. 
We have not yet benchmarked our library in UHC. In GHC, we 
believe it will be as efficient as instant-generics and regular. 

7. Future work 

Our solution is applicable to a wide range of datatypes and can 
express many generic functions. However, some limitations still 
remain, and many improvements are possible. In this section we 
outline some possible directions for future research. 

7.1 Supported datatypes 

Our examples in |Section~2 show that we can represent many com- 
mon forms of datatypes. We believe that we can represent all of the 
Haskell 98 standard datatypes in Representableg, except for con- 
strained datatypes. We could easily support constrained datatypes 
by propagating the constraints to the generic instances. 

Regarding Representablej, we can represent many, but not all 
datatypes. Consider a nested datatype for representing balanced 
trees: 

data Perfect p = Node p \ Perfect (p , p ) 

We cannot give a representation of kind * — > * for Perfect, since 
for the Perfect constructor we would need something like Perfect o 
Reci ((,) p). However, the type variable p is no longer available, 
because we abstract from it. This limitation is caused by the fact 
that we abstract over a single type parameter. The approach taken 
by |Hesselink| [2009 ) is more general and fits closely with our 
approach, but it is not clear if it is feasible without advanced 
language extensions. 

Note that for this particular case we could use a datatype which 
pairs elements of a single type: 

data Pair p = Pair p p 

The representation for the Perfect constructor could then be Perfect o 
Recj Pair. 

7.2 Type-indexed datatypes 

Some generic functionality, like the zipper ( Huet 1 997 1 and generic 
rewriting (Van Noort et al. 2008), require not only type-indexed 
functions but also type-indexed datatypes: types that depend on the 



structure of other types (Hinze et al. 20021. We plan to investigate 
how type-indexed datatypes can be integrated easily in our generic 
deriving mechanism, while still avoiding advanced language exten- 
sions. 

7.3 Generic functions 

The representation types we propose limit the kind of generic func- 
tions we can define. We can express the Haskell 98 standard deriv- 
able classes Eq, Ord, Enum, Bounded, Show, and Read, even lift- 
ing some of the restrictions imposed on the Enum and Bounded 
instances. All of these are expressible for Representableo types. 
Using Representable i , we can implement Functor, as the param- 
eter of the Functor class is of kind * — > * . The same holds for 
Foldable and Traversable. For Typeable we can express Typeableo 
and Typeable ; . 

On the other hand, the Data class has very complex generic 
functions which cannot be expressed with our representation. Func- 
tion gfoldl, for instance, requires access to the original datatype 
constructor, something we cannot do with the current representa- 
tion. In the future we plan to explore if and how we can change our 
representation to allow us to express more generic functions. 

7.4 Efficiency 

The instances derived in our approach are not specialized for a 
datatype and may therefore incur an unacceptable performance 
penalty. However, our recent research (Magalhaes et al. 20 1 0 j) indi- 
cates that simple inlining and symbolic evaluation, present in some 
form in every optimizing compiler, suffice in most cases to opti- 
mize away all overhead from generic representations. We plan to 
investigate how these optimizations can be expressed and automat- 
ically applied without any user intervention in UHC. 

7.5 Implementation in GHC 

Our approach is designed to be as portable as possible. Therefore, 
we would like to implement it in other compilers, most impor- 
tantly in GHC. As a first step, we believe we can easily implement 
most of our generic deriving mechanism in GHC using Template 
Haskell. The code for the generic functions is kept intact: only the 
DERIVABLE pragma needs a different syntax. For the user code, a 
code splice would trigger the generation of generic representations 
and function instances. 

8. Conclusion 

We have shown how datatype-generic programming can be better 
integrated in Haskell by revisiting the deriving mechanism. All 
Haskell 98 derivable type classes can be expressed as generic func- 
tions in our library, with the advantage of becoming easily read- 
able and portable. Additionally, many other type classes, such as 
Functor and Typeable, can be declared derivable. Our extension re- 
quires little extra syntax, so it is easy to implement. Adding new 
generic derivings can be done by generic programmers in regular 
Haskell; previously, this would be the compiler developer's task, 
and would be done using code generation, which is more error- 
prone and verbose. 

We have implemented our solution in UHC and invite everyone 
to derive instances for their favorite datatypes or even write their 
own derivings. We hope our work paves the future for a redefinition 
of the behavior of derived instances for Haskell Prime (Wallace 
|et al.|2007) . 
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